Slice 1 (2/4): repository interface + in-memory & SQLite adapters - #2

The persistence interface is `Store` (not `Repository`, which collided with the `Repo`
domain object). A SQLAlchemy-backed `SqlAlchemyStore` replaces the hand-rolled sqlite3 and
dict-based adapters; "in-memory" is just an in-memory SQLite engine (StaticPool), with
on-disk SQLite as the other tested backend.

- Translators, not ORM-bound core: the pure, frozen domain models stay untouched; the
  adapter's mutable row classes own to_domain/from_domain, and parent->child links are ORM
  relationships (selectin eager-load, cascade insert).
- Integrity enforced by the Store base via template methods: create_task/save_task run
  validate_task_consistency / validate_history_append_only and delegate raw persistence to
  _insert_task / _stored_history / _update_task, so an adapter can't skip the checks.
  _update_task only appends new entries and fulfils the current entry's promises in place.
- Reflective tests guard that rows and domain dataclasses can't drift. Schema via
  metadata.create_all; Alembic deferred (BACKLOG).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>